An upgrade is the procedure to transform a productive software system from one major software version to a newer version. As shown in FIG. 1, the system 100 includes one or more application core servers 102. Each core server 102 hosts sessions and runs services and applications (short: programs). Sessions are initiated from outside of the system. A core server infrastructure 104 routes the incoming request to an application server of the core servers 102, which then creates the session. Subsequent requests in the context of the session will be routed to the same core server 102. New requests without session will be distributed again to one of the core servers.
It can be assumed that the systems expose singletons, which are programs that can only run once throughout the entire system (regardless of the number of core servers) since they rely on unique data kept in memory local to a core server. Upgrades depend heavily on the classification of data in a database 106. For the upgrade there is a need to classify the data in the database 106 along multiple orthogonal dimensions.
Along the functional dimension, the data can be classified as follows:                program data (short: data): comprising all data created by the programs' operation incl. master data        Configuration: business configuration (customizing) and technical configuration. Insomuch as master data influences the functional behavior/flow of programs and thus behaves like configuration, master data may also be classified as configuration.        Code: code of programs (services and applications) including generated code. This is the data interpreted by the core server and maybe even services in order to actually run the program        
Code and configuration data are combined into an empty, but runnable program. This means that the program can run without errors and provide the functionality it was designed for with program data tables basically being empty. The term data as used herein also includes the data structures (e.g. table layouts, DDIC entries).
Along the upgrade-impact dimension the data can be classified as follows:                To-remain-unchanged data: Data that is kept without change imposed by the upgrade.        To-Be-Changed data: Data that needs to be transformed by the upgrade. In general, change is associated with physical changes such as structural changes (i.e. differing table layout), exchanging or altering data (i.e. exchange old with new code or replacing a default value, deleting old and adding new example data, . . . ). For the upgrade it is important to understand that also semantical or logical changes play a non-neglectable role. Semantical changes manifest in the worst case such that even physically unchanged data is interpreted differently by original and target programs and therefore have to be treated as changed data during upgrade in order to avoid inconsistencies when reading and writing to the data.        
Along the changeable-by-customer dimension the data can be classified as follows:                Unchangeable data: Data delivered by a system provider, such as SAP, that cannot be changed by a customer (in general this is code)        Changeable data: Data delivered by the system provider that is changed by the customer (e.g. configuration entries)        Customer-created data: Data that is perceived as singletons by the upgrade since they have solely been created by the customer (e.g. business data entered by means of the various applications). The data is singleton since the consistency of the business operation of the system assumes no copies of individual data records.        
Conventional upgrades, however, always require interruption of all end user work, leading to business and technical downtime perceived by the end user while keeping the central processing unit (CPU) and memory consumption low.